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(57) ABSTRACT 

An apparatus and method provides arbitration among a 
plurality of subscribers and also provides access isolation 
between a requester, such as a subscriber or other entity, and 
a security-related information source, such as a repository 
containing certificates and certificate revocation lists (CRL^) 
or other security-related information. The system and 
method isolates the requester from the source by generating 
separate security information release-data to obtain the 
security-related information firom the source based on ana- 
lyzed request criteria-data. The arbitration module generates 
a separate security-information release request to the reposi- 
tory to retrieve appropriate data from the internal repository 
in response to the externally generated request without 
allowing the request to filter directly through to the security- 
related information source. 

36 Claims, 4 Drawing Sheets 
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METHOD AND APPARATUS FOR secondary special purpose firewalls. These special purpose 

PROVIDING ACCESS ISOLATION OF firewalls are typically used to filter LDAP requests and allow 

REQUESTED SECURITY RELATED accepted LDAP requests to be passed to the target LDAP 

INFORMATION FROM A SECURITY server thereby allowing a client direct access to the server. 

RELATED INFORMATION SOURCE 5 Again, such firewall-based systems still can expose highly 

sensitive corporate information to an outsider if the outsider 

PiFT n OP THP iMVPMTinM ^ allowed to pass through the firewall, and have end-to^nd 

FIELD OF THE INVENTION ^ .^^^^^^ ^^^^^^ 

-nie invention relates generaUy to information security other information-security systems, such as those that 

systems and methods and more particularly to mfonnation lo employ public key cryptography, have certification authori- 

security systems and methods that provide isolation between ties that post certificates lo a repository and a subscriber that 

a requestor and a security infonnation source. obtains the signed certificates directly from the repository. 

BACKGROUND OF THE INVENTION Such systems typically also allow end-to-end access of the 

Secure computer systems and other systems are known subscriber to the repository and typically require the same 

which use cryptographic techniques to encrypt and decrypt P^^°^^ ^'^^^^^^ ^ subscriber and the repository, 

data sent from one computer or user to another computer Accordingly, there exists a need for a system and method 

within a network. In typical public key cryptographic ^^^^^ scalcable dissemination of the requisite 

systems, digital signature key pairs, such as a signature security-related information, such as certificates, CRLs, and 

private key and a verification public key, are used to 20 o/^^^r security information, without introducing such poten- 

authenticate a digital signature of a client to ensure that a security concerns relating to access to valuable corporate 

message sent by client actually came from the client sending resources, or requiring unaccepuble operational overhead, 
the message and has not been altered. Generally, data is 

digitally signed by a sender using the signature private key ^^^EF DESCRIPTION OF THE DRAWINGS 

and authenticated by a recipient using the verification pubUc ^5 The invention will be more fully understood in view of the 

key. In addition to digital signature key pairs, encryption key below description in conjunction with the accompanying 

pairs are also generally used to encrypt the data being sent drawings. 

from one client to another client. An encryption key pair nir- -n * ♦* u j- . r 

• 1 J J ... J FIG. 1 is block diagram illustrating one embodiment of a 

mcludes a decryption private key and an encryption public , , . * . r viii^^uii^m a 

r» t • * A • Li* 1 J system employing an apparatus for providmg isolation 

key. Data IS encrypted using the encryption public key and ,n «1™ * a •* 1.^ c c 

. . . ° 4U J *• • * 1 access of requested security-related mformation from a 

decrypted by a recipient usmg the decryption pnvate key, ^1 ♦ ^ • <• ♦* • j 

r>*.r«;fio.*«o i« u » * J security-related mformation source m accordance with one 

Certincales are generated by a manager or trusted certifica- t /- * r .1. • 

«• .u c I.V 1 r .i_ • embodiment of the invention, 
tion authority for the pubhc keys of the private/public key 

pair to certify that the keys are authentic and vaUd. ^ ^ ^ ^^^^^ diagram illustrating one example of a 

artificates and certificate revocation lists (CRLs) should 35 '^'^''^^} accordance with one embodiment of the 

be freely disseminated in order to facilitate the secure liivention. 

exchange of e-mail as well as other global applications, such FIGS. 3a and 36 is a flow chart illustrating the operation 

as electronic commerce. However, there is increasing con- °^ system shown in FIG. 1. 

cern shared by many enterprise domainsthat uncontrolled nPTAn nn nccr-DiimrMa r^r ttjc 

dissemination of certificates and CRLs will introduce polen- 40 no^c^^n 

tial vulnerabilities. When possible, vulnerability may be FKLhbRRED EMBODIMENTS 

introduced as a result of outsiders obtaining access to Briefly, an apparatus and method provides arbitration 

sensitive databases or repositories where the certificates and among a plurality of requesters and also provides access 

CRLs are stored, such as X.500 directories, or other public isolation between a requester, such as a subscriber or other 

key infirastructure (PKI) repositories, as known in the art, 45 entity, and a security-related information source, such as a 

within the corporate network system. This has led to an repository containing certificates and CRLs or other 

unwillingness among a number of organizations to share security-related information. The system and method iso- 

their corporate database information. Generally, there is also lates the requester from the source by generating separate 

an unwillingness to replicate or copy certificates and CRLs security information release-data to obtain the security- 

to external repositories because of the operational overhead 50 related information from the source based on analyzed 

with doiiig so and the difficulty in insuring that the replicated request criteria-data. As such, in one embodiment, an arbi- 

information does not become obsolete or become trusted tration module is set up between a networked infrastructure, 

when it should not be. such as a corporate infrastructure and external-end users! 

One known technique for isolating an information The arbitration module receives requests from external users 

requester or subscriber within a networked community, is 55 for security information and determines whether or not the 

the use of a firewall server or computer. In such well-known request should be satisfied. The arbitration module generates 

systems, the requester is granted access to a target resource a separate security- information release request, consisting of 

within a secure system after passing through the firewall separate security release data, to the repository to retrieve 

computer. As such, the requester is typically granted direct appropriate data firom the internal repository in response to 

access to the target resource. Access is typically granted 60 l^e externally generated request without allowing that 

based on access control information sent in an initial access request to filter directly to the internal repository, 

request. However, such firewaU-based systems still can in one embodiment, pre-processing is done prior to 

expose highly sensitive corporate information to an outsider responding to the request, such as checking revocation status 

if the outsider is allowed to pass through the firewaU. and of a signed request prior to supplying a certificate The 

have end-lo-cnd access to an internal system. 55 request criteria data used by the arbiter includes, for 

Also, light weight directory access protocol (LDAP) example, the type of data to obtain from the security-related 

proxy servers are known, that are used with firewalls as information source, a priori knowledge of the target end- 
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user's e-mail address, source domain name, source certifi- a confirmatioD request from another requester must first be 

cation authority in the event that certificate-based authenti- received, or other suitable conditional criteria -data. It vsdll be 

cation is used, source IP address data, or portion thereof, recognized that any suitable request criteria may also be 

privilege or permission information of the source, or any used if desired. 

""^^'^y s^^We criteria 5 The security-information request arbiter 12 also arbitrates 

Differmg protocols may be used between the requester ^ ^ ^^^^^^ ^^^^^^ security-information requests 

and arbiter and between the arbiter and the information ^ased on the security^riteria data 28. For example, if a 

source. For example, connectivity between the external i r. c . • j • j * 

end-user and the arbiter can be facilitated through Pl^rahty of requests are received, the secunty^ntena data 

connectionless, connection-oriented, session connection or ^^^y ^icate that a request from a given requester takes 

store-and-forward techniques, for example. HTTP, Light- '° ^IT^^ l^"^""^^ ^''^^^^ 

weight Directory Access Protocol (LDAP), File Trar^fer ^"^'^'^^'^ 

Protocol (FTP), e-mail and any other suitable protocol. '^ach requester Ua-Un generates a secunty information 
Likewise, back-end connectivity between arbiter and the request 30 and 32, representing a request for the security- 
repository can be any suitable protocol. related information from at least one of the sources 14a-14/i. 

FIG. 1 shows a system 10 employing a security- ^*^"*y informadon request may be communicated to 
information request arbiter 12 to provide isolation of access ^^"*y information request arbiter 12, using any suit- 
requests between security-related information from a P^^^^^' ^ security information request 
security-related information source 14a-14/i and one or 30 from requester A 16a may be m a different format 
more requesters 16a-6rt. Hie security-information request ,0 ^^^l ^''''''^^ informaUon request data 32 
arbiter 12 and security-related information sources Ua-i4n requester B I6/1. The security information 
may be. for example, part of a corporate infrastructure 18. f ^^^^^ ^^^^^^ isolates a respective requester 16a-16n 
However, it wUl be recognized that the security-related respective secunty-related information source 
information sources 14fl-14/j may be outside of the corpo- 14a-14fi by generating separate security information release 
rate infrastrucUire desired. The security-information request .5 ^^^^^ secunty mformation from the source, 
arbiter 12 may be a suitably programmed computer, such as ^^^^^ granted based on analyzed request criteria data 28 
an IBM-compatible PC, or any suitable processing device. ^ S^^^" requester. For example, if the request-criteria 
The requester 16a-16/i may also be any suitable processing approved requesters and the requester 16a is 
unit, software application, or any other suitable entity not on the list, the separate security information release-data 
requesting access of security information from a security- 30 ^f^" ^ .^^l ^? repository. Instead, a security- 
related information source. Security information may information reply 40. mdicating a refusal, will be returned to 
include, for example, cryptography-rclated security data requester. However, if the secunty information request 
such as public key certificates, CRU passwords, crypto- ^eludes a request for identification data that satisfies the 
graphic algorithms, and non-cryptographic infonnation used cnicn^ the secunty-infonnation reply data 40 will 
in some way to secure information stored in the information 35 requested secunty mformation from the relevant 
source 14a~14n. repository. 

The repository 14fl-14« may be any suitable storage ^° ^ alternative embodiment, the security-information 
medium and may also be, for example, certificate reposito- ^^^^^^^ ^^^^^^ generates the reply data based on a response 
ries such as an X,500-based repository, database, or file separate security-information release 
system. As known in the art of public key cryptography, for 40 "^^Y^^ ^ always sent in response to a security- 
example, the repository may be accessible by a plurality of information request. 

other servers such as certification authorities 20tz-20/i. The separate security-information release data is evalu- 

which generate signed public key-based certificates for ^^^^ ^y the repository. The repository then returns stored 

requesters or other subscribers to the system. Other sub- security-related data 42 back to the security-information 

scribers are shown as subscribers 22^-22/1, which may be 45 request arbiter who then passes the security-related data as 

included in the corporate infrastructure, or may also be of the security information reply 40 back to the suitable 

outside of the corporate infrastructure but also have access requester. 

to the repositories. Other information security-related ser- Referring to the FIGS, 2, 3a, and 3£>, one example of the 

vices such as attribute authorities 24 may also have access security-information request arbiter 12 includes a request 

to the respective repositories if desired. Attribute authorities, 50 analyzer 50, a security-information retriever 52, and a reply 

as known in the art, issue and revoke attribute certificates generator 54. If desired, a data filter 56, a reply cuslomiza- 

rathcr than public key certificates. These certificates and tion engine 58 and a digital signing engine 60 may also be 

associated revocation lists are managed similarly to public used. 

key certificates and revocation lists. The request analyzer 50 determines, based on the requesl- 
The security-information request arbiter 12 may include 55 criteria data 28, whether to allow a security-information 
or be coupled to a graphic user interface 26 to receive or request and the type of data to obtain from the security- 
otherwise obtain request-criteria data 28. Request criteria- related information source. The request -criteria data may be, 
data 28 may include, for example, a list of approved request- for example, a look-up table, having a column listing of the 
crs and the type of data obtainable from a repository for a allowable requesters for which the request analyzer will 
given requester. As such, the request criteria-data may 60 approve or allow security information to be obtained from 
include approved requester identification data such as a the source, as well as another column indicating the type of 
requester number, data representing releasable security- data for that specific requester or group of requesters that can 
related information from the source such as releaseable be obtained. For example, certain requesters may be limited 
public key certificates, CRLs and conditional criteria-data to to retrieving only certificate information, whereas other 
facilitate the release of security-related information from the 65 requesters having higher security clearance may be allowed 
source, such as conditions that must first be met before to obtain security information for other purposes. The 
releasing the data. One example of a condition may be that request analyzer 50 may obtain the request-criteria data 28 
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from lookup tables stored in cache memory or other suitable 
locations. In addition, if desired, the request analyzer 50 may 
also include an alarm threshold or series of alarm thresholds 
that when triggered, generate a security alarm signal 51 to a 
display device or a log table, indicating that a particular 
requester has breached security by requesting information 
not allowed, or indicated as approved for, by the request- 
criteria data. As such, the sectirity-informatioa request arbi- 
ter may notify a security ofiBcer of a potential breach in 
security. 

Where the security-information request data 30 includes a 
public key-based certificate or other certificate having a 
digital signature, the request analyzer 50 may also include a 
digital signature verifier 62, operative to verify digital sig- 
natures associated with the security information-request 
data. Any suitable digital signature verifying algorithm may 
be used, such as RSA, DSA, or elliptic curve algorithms. In 
such a system, if desired, the arbiter 12 may also include a 
digital signing engine 60, which applies a digital signature 
of the arbiter to the selected security-related data from the 
source, namely the retrieved information (security-related 
data 42), resulting in the reply data 40. The digital signature 
generates a verifiable digital signature for the reply data 40. 
Again, any suitable digital signing algorithm may be used, 
such as RSA, DSA, or elliptic curve algorithms. 

In this embodiment, the security-information request ana- 
lyzer 50 receives the security information request data 30 in 
a first protocol such as an HTTP-based format and generates 
the separate security information release data 34 in a second 
protocol such as FTP, suitable for obtaining selected 
security-related information from the source. This may be 
done, for example, by the request analyzer generating 
retrieve/request data 66 after a digital signature correspond- 
ing to the requester as part of the security-information 
request data 30 has been verified and once the request 
criteria data 28 indicates that a separate security information 
release data should be generated. If the digital signature does 
not verify, or if the request criteria data indicates that this 
requester cannot obtain the requested security-information, 
the rejection-notice data 68 is then sent to the reply generator 
54. The reply-data generator 54 may be a protocol formatter 
which puts the rejection notice or selected retrieved infor- 
mation from the repository in a suitable protocol format for 
proper understanding by the requester. 

The reply data 40 for the requester includes retrieved 
security-related data obtained from the source in response to 
the separate security information release data 34. Optionally, 
the system may include the data filter 56, which is opera - 
lively coupled to filter retrieved security-related data 
obtained from the source in response to the separate 
security-information release data. The filtering is done based 
on filter-criteria data. For example, the filter-criteria data 
(which is entered through the graphic user interface or other 
mechanism) may include data that should be filtered for a 
given requestor or for a certain type of request. Filtering 
includes removing or modifying data prior to communicat- 
ing the reply data for the requester. Modifying data includes 
adding to or altering the data, for example encrypting it. As 
such, the data filler 56 analyzes the retrieved information 
from the repository and compares it to the rest of the types 
of data that require filtering, and if the type of data appears 
on the list, the data may be modified, or removed so that 
superfluous information is not sent to a requester. 

As an additional option, the arbiter 12 may include a data 
customizer or customization engine 58 that is coupled to 
customize the retrieved security-related data obtained from 
the source in response to the separate security-information 
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release data by at least adding additional data to the retrieved 
security-related data. The additional data may include, for 
example, contact information, source site identification data, 
or corporate branding information. The arbiter may also 

5 include or have access to memory 70 which may contain 
stored customized retrieve security- related data for later use 
in response to subsequently received security-information 
request data so that the data does not need to be again 
obtained from the repository, such as certificates, CRLs or 

■^Q other data. The storage device 70 may also contain pending 
security information- request data that is yet to be processed 
and associated reply data to facilitate tracking of request 
data and corresponding reply data to facilitate, for example, 
billing to requesters who are requesting information on a 

J5 periodic basis. 

Referring to FIGS. 3a and 3b, the system obtains security- 
criteria data as shown in block 100. This information can be 
obtained, for example, prior to a request being received or 
after a request is received if desired, and may be obtained, 

20 for example, from any suitable memory. As shown in block 
102, the system stores the security-criteria data for later 
evaluation. This information may be stored, for example, in 
the form of a look-up table or in any suitable form. As shown 
in block 104, the arbiter then receives the security informa- 

25 tion requested through a suitable transceiver such as a 
modem, RF link, or any other suitable communication link 
and in any suitable format. As shown in block 106, the 
arbiter analyzes the request in view of the security-criteria 
data by comparing the information in the request with the 

30 request criteria data. For example, the security criteria data 
may specify that incoming security information request data 
must include a digital signature by the requestor, so that the 
requestor may be authenticated to the arbiter. As another 
example, the security criteria data may specify that incoming 

35 security information request data must include billing infor- 
mation sufficient to appropriately bill the requestor for the 
value of the information requested. 

As shown in block 108, the arbiter determines if the 
security alarm threshold has been met. If the security alarm 

40 threshold has been met, an alarm is generated as shown in 
block 110. This may occur, for example, if a same requester 
has requested information that is not listed in the request- 
criteria data for that specific requester for a predetermined 
number of times. As shown in block 112, the system 

45 determines if the request has been accepted, meaning that 
the request-criteria data matches the data within the security- 
information request. If the request has not been accepted, the 
system generates a rejection reply, as shown in block 114. 
However, if the request has been accepted, the system 

50 determines, as shown in block 116, whether a customized 
reply exists in the memory 70. This may occur, for example, 
if a previous request and reply was generated and the reply 
was cached and the same request has been requested within 
an allowable time frame. If the customized reply does not 

55 exist, the system stores the pending request in memory, as 
shown in block 118, As shown in block 120, if a customized 
reply does exist for the particular security-information 
request, the system sends a reply obtained from memory 70, 
as shown in block 120. 

60 As shown in block 122, after the pending request has been 
stored, the system generates the separate security informa- 
tion request. As shown in block 124, the arbiter then sends 
the separate security-information release data 34 to query 
the repository. As shown in block 126, the arbiter through 

65 the security-information retriever, determines the content 
security related data 42 to determine whether the repository 
reply includes the requested information. If the repository 
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does not include the requested information, a rejection reply 
is generated. However, if the repository reply does include 
the requested information, the system, as shown in block 
128, filters the data lo remove or modify sensitive informa- 
tion based on the filter-criteria data. 5 

As shown in block 130, the system customizes the 
retrieved security-related data obtained from the source in 
response lo the separate security- informal ion release data by 
adding additional data to the retrieved security-related data, 
llie additional data may include, for example, contact jq 
information, source site identification data, or corporate 
branding information. 

As shown in block in block 132, the system generates the 
reply for the pending request, which may include a digitally 
signed reply and also store the customized data for future 
reference in the repository or in cache memory if desired, as 
shown in block 134. As shown in block 136, the system may 
optionally log or store the request and the generated reply for 
a given requester for billing purposes and tracking purposes 
to facilitate an accountability of, and record of, obtained 
information from the repository. Where the security infor- 
mation request is digitally signed and where the reply is 
digitally signed, the system may operate by validating data 
associated with the security information request data, such 
as the signature, and generating validalable reply data, such 
as the signed reply, using at least one of: digital signatures, 
timestamps, revocation information, policy data, checksums 
or any other suitable validatable data. 

As such, the above-described system provides arbitration 
with access isolation to isolate a requester firom the security- ^ 
information source so that the requester cannot directly 
access or otherwise obtain access to the sensitive informa- 
tion in the repository. Moreover, the system allows commu- 
nication in different protocols between a requester and the 
arbiter and the arbiter and the repository, and as such can 
flexibly handle communication with many different types of 
requesters. Where a reply is digitally signed, the system 
affords a trusted verification that the information was 
obtained not only from a trusted repository but by a trusted 
arbiter. 

40 

It should be understood that the implementation of other 
variations and modifications of the invention in its various 
aspects will be apparent to those of ordinary skill in the art, 
and that the invention is not limited by the specific embodi- 
ments described. It is therefore contemplated to cover by the 45 
present invention, any and all modifications, variations, or 
equivalents that fall within the spirit and scope of the basic 
underlying principles disclosed and claimed herein. 

What is claimed is: 

1. A method for providing requested security related 
information from a security related information source com- 
prising the steps of: 

receiving, from a requestor, secuirity information request 
data representing a request for the security related 
information from the source; 55 

isolating the requestor from the source by generating 
separate security information release data, to obtain the 
security related information from the source based on 
analyzed request criteria data; and 

generating reply data for the requestor based on a 60 
response to the separate security information release 
data. 

2. The method of claim 1 including the step of arbitrating 
among a pluirality of received security information requests 
based on the request criteria data. 65 

3. The method of claim 2 wherein the step of arbitrating 
includes determining, based on the request criteria data. 
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allowance of a security information request and a type of 
data to obtain from the security related information source. 

4. The method of claim 1 wherein the step of receiving 
includes receiving the security information request data in a 
first protocol based format and wherein the step of gener- 
ating the separate security information release data includes 
generating the separate security information release data in 
a second protocol suitable for obtaining selected security 
related information from the source. 

5. The method of claim 1 wherein the response to the 
separate security information release data includes selected 
security related data from the source. 

6. The method of claim 1 including the step of obtaining 
the request criteria data and wherein the request criteria data 
includes at least one of: approved requestor identification 
data, data representing releasable security related informa- 
tion from the source and conditional criteria data to facilitate 
the release of security related information from the source. 

7. The method of claim 1 wherein the reply data for the 
requester includes retrieved security related data obtained 
from the source in response to the separate security infor- 
mation release data. 

8. The method of claim 1 including the step of filtering 
retrieved security related data obtained from the source in 
response to the separate security information release data 
based on filter criteria data. 

9. The method of claim 8 wherein the filler criteria data 
includes data representing sensitive data that should be 
filtered prior to communicating the reply data for the 
requestor. 

10. The method of claim 1 including the step of custom- 
izing retrieved security related data obtained from the source 
in response to the separate security information release data 
by at least adding additional data to the retrieved security 
related data. 

11. The method of claim 10 including the step of storing 
customized retrieved security related data for later use in 
response to subsequently received security information 
request data. 

12. The method of claim 1 including the steps of validat- 
ing data associated with the security information request 
data and generating validatable reply data, where validation 
of the validatable reply data includes use of at least one of: 
digital signatures, timestamps, revocation information, 
policy data, and checksums. 

13. The method of claim 1 including the step of storing 
pending security information request data and associated 
reply data to facilitate tracking of request data and corre- 
sponding reply data. 

14. A method for providing requested security related 
information from a security related information source com- 
prising the steps of: 

receiving, from a requester, security information request 
data representing a request for the security related 
information from the source; 

arbitrating among a plurality of received security infor- 
mation requests based on request criteria data; 

obtaining the request criteria data and wherein the request 
criteria data includes at least one of: approved requestor 
identification data, data representing releasable security 
related information from the source and conditional 
criteria data to facilitate the release of security related 
information from the source; 

isolating the requestor from the source by generating 
separate security information release data, to obtain the 
security related information from the source based on 
analyzed request criteria data or security information 
release data; and 
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generating reply data for the requester based on a 
response to the separate security information release 
data wherein the reply data for the requestor includes 
retrieved security related data obtained from the source 
in response to the separate security information release 
data. 

15. The method of claim 14 wherein the step of arbitrating 
includes determining, based on the request criteria data» 
allowance of a security information request and a type of 
data to obtain from the security related information source. 

16. The method of claim 15 wherein the step of receiving 
includes receiving the security information request data in a 
first protocol based formal and wherein the step of gener- 
ating the separate security information release data includes 
generating the separate security information release data in 
a second protocol suitable for obtaining selected security 
related information from the source. 

17. The method of claim 15 wherein the response to the 
separate security information release data includes selected 
security related data from the source. 

18. The method of claim 15 including the step of filtering 
retrieved security related data obtained from the source in 
response to the separate security information release data 
based on filter criteria data. 

19. Ilie method of claim 18 wherein the filter criteria data 
includes data representing sensitive data that should be 
filtered prior to communicating the reply data for the 
requestor. 

20. The method of claim 19 including the step of cus- 
tomizing retrieved security related data obtained from the 
source in response to the separate security information 
release data by at least adding additional data to the retrieved 
security related data. 

21. The method of claim 20 including the step of storing 
customized retrieved security related data for later use in 
response to subsequently received security information 
request data. 

22. The method of claim 21 including the steps of 
validating data associated with the security information 
request data and generating validatable reply data, where 
validation of the validatable reply data includes use of at 
least one of: digital signatures, timestamps, revocation 
information, policy data, and checksums, 

23. The method of claim 22 including the step of storing 
pending security information request data and associated 
reply data to facilitate tracking of request data and corre- 
sponding reply data. 

24. An apparatus for providing requested security related 
information from a security related information source com- 
prising: 

a security information request analyzer that receives, from 
a requestor, security information request data repre- 
senting a request for the security related information 
from the source and isolates the requestor &om the 
source by generating separate security information 
release data, to obtain (he security related information 
from the source based on analyzed request criteria data; 
and 
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a reply data generator, operatively coupled to the security 
information request analyzer, that generates reply data 
for the requestor based on a response from the source 
to the separate security information release data, 
^ 25. The apparatus of claim 24 including an arbiter opera- 
tive to arbitrate among a plurality of received security 
information requests based on the request criteria data. 

26. The apparatus of claim 25 wherein the arbitor 
determines, based on the request criteria data, allowance of 

10 a security information request and a type of data to obtain 
from the security related information source. 

27. The apparatus of claim 24 wherein the security 
information request analyzer receives the security informa- 
tion request data in a first protocol based fonnat and gen- 

15 erates the separate security information release data in a 
second protocol suitable for obtaining selected security 
related information from the source. 

28. The apparatus of claim 24 wherein the response to the 
separate security information release data includes selected 

20 security related data from the souirce. 

29. The apparatus of claim 24 where in the security 
information request analyzer obtains the request criteria data 
and wherein the request criteria data includes at least one of: 
approved requestor identification data, data representing 

25 releasable security related information from the source and 
conditional criteria data to facilitate the release of security 
related information from the source. 

30. The apparatus of claim 24 wherein the reply data for 
the requester includes retrieved security related data 

30 obtained from the source in response to the separate security 
information release data. 

31. The apparatus of claim 24 including an information 
fiher operatively coupled to filter retrieved security related 
data obtained from the source in response to the separate 

35 security information release data based on filter criteria data. 

32. The apparatus of claim 31 wherein the filter criteria 
data includes data representing sensitive data that should be 
filtered prior to communicating the reply data for the 
requestor. 

^ 33 . The apparatus of claim 24 including a data customizer 
operatively coupled to customize retrieved security related 
data obtained from the source in response to the separate 
security information release data by at least adding addi- 
tional data to the retrieved security related data. 

^5 34, The apparatus of claim 33 including a storage device 
containing customized retrieved security related data for 
later use in response to subsequently received security 
information request data. 

35. The apparatus of claim 24 including a digital signature 
50 verifier operative to verify a digital signature associated with 

the security information request data and generating a veri- 
fiable digital signature for the reply data. 

36. ^ITie apparatus of claim 24 including a storage device 
containing pending security information request data and 

55 associated reply data to facilitate tracking of request data 
and corresponding reply data. 

♦ 4> * 4 « 
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